There appear to be 2 other options (but read below for why these are poor):
* redefine Circle::scale(x,y) to throw an exception or call 'abort()'.
* redefine Circle::scale(x,y) to be a no-op, or to scale both dimensions by the average of the parameters (or some other arbitrary value).
Throwing an exception will 'surprise' clients. You claimed that a Circle was actually a kind of an Ellipse, so they pass a Circle off to 'f(Ellipse& e)'. The author of this function read the contract for Ellipse very carefully, and scale(x,y) is definitely allowed. Yet when f() innocently calls e.scale(5,3), it kills him! Conclusion: you lied; what you gave them was distinctly *not* an Ellipse.
In the second case, you'll find it to be very difficult to write a meaningful semantic specification (a 'contract') for Ellipse::scale(x,y). You'd like to be able to say it scales the x-axis by 'x' and the y-axis by 'y', but the best you can say is 'it may do what you expect, or it may do nothing, or it may scale both x and y even if you asked it to only scale the x (ex: 'scale(2,1)'). Since you've diluted the contract into dribble, the client can't rely on any meaningful behavior, so the whole hierarchy begins to be worthless (it's hard to convince someone to use an object if you have to shrug your shoulders when asked what the object does for them).
